Hi! This is my first contribution to JHipster. I've implemented the fix requested in #30206 by removing offline_access from the default OAuth2 scope configuration. Please let me know if any changes are needed. Thanks!

Ionic blueprint uses offline_access. It’s not a fix without further investigation.

Thank you for the review and the helpful context, @mshima — I wasn’t aware that the Ionic blueprint depends on offline_access, so that’s great insight.

I’ll investigate how and where the Ionic blueprint uses this scope, and ensure my fix doesn’t break that functionality. My plan is to:

• Confirm if offline_access is essential for Ionic apps
• Evaluate whether it can be made conditional based on application type
• Preserve Ionic functionality while improving the defaults for others

I’ll update the PR accordingly. Meanwhile, if you have any suggestions on where best to look for the Ionic blueprint’s use of offline_access, I’d appreciate the guidance!

Ionic blueprint uses offline_access. It’s not a fix without further investigation.

I think that, for now, the change should be only in the application.yml of the gateway, in case it is used for web applications.

However, the management of the scope requires analysis in the case of microservices currently registered with the internal client issuer.

• In the case of batch flows with Keycloak, the concept of a service account could be used. The developer should be responsible for configuring this service account with the appropriate roles and client resources in order to access the various APIs and generate tokens using that account. In such cases, the auditor (i.e., the user present in the Spring Authentication Context) will be service-account-internal and not the actual user, but I believe this is correct for batch flows.

In the case of offline flows (that need to access resources on behalf of the user even when the user is not online), the offline_access scope should be requested, but only if an SSO session was previously created without this scope (for web applications). Anyway, the management should be such that the token is reused for refresh as long as it is valid; otherwise, there's a risk of creating too much offline sessions in Keycloak that will never actually be used and that Keycloak will only clean up after a certain amount of time.

I believe the last two points should be implemented by whoever uses JHipster, based on their specific needs — unless JHipster provides predefined utilities to simplify development.

@mshima @mraible

Following your feedback, I investigated both proposed paths. It turns out there's only one universal application.yml template used across all application types, so a targeted “gateway-only” edit isn’t feasible.

To address @mshima’s valid concern about the Ionic blueprint, while still fixing the SSO bug in web apps (per @ldaloia-dev's suggestion), I’ve updated the PR to include the offline_access scope only when clientFramework === 'ionic'.